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Abstract 

Total functional programming offers the beguiling vision that, just 
by virtue of the compiler accepting a program, we are guaranteed 
that it will always terminate. In the case of programs that are not in¬ 
tended to terminate, e.g., servers, we are guaranteed that programs 
will always be productive. Productivity means that, even if a pro¬ 
gram generates an infinite amount of data, each piece will be gen¬ 
erated in finite time. The theoretical underpinning for productive 
programming with infinite output is provided by the category theo¬ 
retic notion of final coalgebras. Hence, we speak of coprogramming 
with non-well-founded codata, as a dual to programming with well- 
founded data like finite lists and trees. 

Systems that offer facilities for productive coprogramming, 
such as the proof assistants Coq and Agda, currently do so through 
syntactic guardedness checkers, which ensure that all self-recursive 
calls are guarded by a use of a constructor. Such a check ensures 
productivity. Unfortunately, these syntactic checks are not compo¬ 
sitional, and severely complicate coprogramming. 

Guarded recursion, originally due to Nakano, is tantalising as a 
basis for a flexible and compositional type-based approach to co¬ 
programming. However, as we show, guarded recursion by itself is 
not suitable for coprogramming due to the fact that there is no way 
to make finite observations on pieces of infinite data. In this paper, 
we introduce the concept of clock variables that index Nakano’s 
guarded recursion. Clock variables allow us to “close over” the 
generation of infinite codata, and to make finite observations, some¬ 
thing that is not possible with guarded recursion alone. 

Categories and Subject Descriptors D.1.1 [Programming tech¬ 
niques]: Applicative (functional) programming; D.2.4 [ Software 
Engineering ]: Software/Program Verification; D.3.3 [Program¬ 
ming Languages ]; Language Constructs and Features—Data types 
and structures 

General Terms Languages, Theory, Types, Recursion 

Keywords coalgebras, corecursion, guarded recursion, total func¬ 
tional programming 

1. Introduction 

Coprogramming refers to the practice of explicitly manipulating 
codata, the non-well-founded dual of well-founded data like finite 
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lists and trees. Codata are useful for representing the output of 
an infinite process as a never ending stream, or for representing 
potentially infinite search trees of possibilities. The natural way to 
express codata is as a recursively defined coprogram. However, for 
recursively defined coprograms to be safely used in a total setting, 
the system must ensure that all recursive definitions are productive. 
The state of the art for productivity checking is currently either 
awkward syntactic guardedness checkers, or more flexible sized 
type systems that explicitly label everything with size information. 

In this paper, we investigate the use of guarded recursion (due 
to Hiroshi Nakano [20]) as a lightweight typing discipline for en¬ 
abling productive coprogramming. As we show in this introduction, 
guarded recursion by itself is not suitable for coprogramming, due 
to the strict segmentation of time inherent in putting guardedness 
information in types. We therefore introduce the concept of clock 
variables to take us from the finite-time-sliced world of guarded 
recursion to the infinite world of codata. 

The contributions we make in this paper are the following: 

1. We define a core type system for comfortable productive co¬ 
programming, combining three key features: initial algebras, 
Nakano’s guarded recursion and our main conceptual contribu¬ 
tion: quantification over clock variables. We show that by com¬ 
bining the three key features of our system, we obtain a system 
for programming with final coalgebras, the category theoretic 
description of codata. The combination of guarded recursion 
and clock quantification allows us to dispense with the clunky 
syntactic guardedness checks, and move to a flexible, composi¬ 
tional and local type-based system for ensuring guardedness. 

2. We define a domain-theoretic denotational model that effec¬ 
tively interprets our system in the untyped lazy A-calculus. We 
use a multiply-step-indexed model of types to prove that all 
well-typed programs are either terminating or productive and to 
show the correctness of our reconstruction of final coalgebras. 

3. A side benefit of the combination of guarded recursion and 
clock quantification is that, due to the careful tracking of what 
data is available when through guarded types, we are able to 
accurately type, and show safe, strange circular functional pro¬ 
grams like Bird’s replaceMin example. 

Despite the large amount of recent work on guarded recursion 
(we provide references throughout this introduction), this is the 
first paper that formally links guarded recursion to productive co¬ 
programming. As recently noted by Birkedal and Mpgelberg [4], 
“guarded recursive types can be used to [sic] as a crutch for higher- 
order programming with coinductive types”. In this paper, we show 
that this is indeed possible. 

1.1 Guardedness checkers and guarded recursion 

Several systems with support for corecursion, such as Coq (as de¬ 
scribed by Gimenez [12]) and Agda (as described by Danielsson 
and Altenkirch [9]), make use of syntactic guardedness checks to 


ensure productivity of programs defined using corecursion. With¬ 
out these checks, the soundness of these systems cannot be guar¬ 
anteed. An unfortunate aspect of these guardedness checks is their 
non-compositionality. We demonstrate the problem with an exam¬ 
ple, and see how Nakano’s guarded recursion can be used to pro¬ 
vide a compositional type-based guardedness check. 

We will use Haskell notation for each of our informal examples, 
since it serves to illustrate the issues concisely. Consider the follow¬ 
ing Haskell declaration of a type of infinite streams of integers: 
data Stream = StreamCons Integer Stream 

An example of a Stream is the infinite stream of Is: 
ones :: Stream 
ones = StreamCons 1 ones 

It is easy to see that this recursive definition is guarded', ones 
is only invoked recursively within an application of the stream 
constructor StreamCons. This definition of ones defines an infinite 
data structure, but each piece of the data structure is delivered to us 
in finite time. Hence, ones is productive. 

An example of a non-guarded definition is the filter function, 
extended from finite lists to infinite streams: 

filter :: (Integer —> Bool) —>• Stream —> Stream 
//ter/ (StreamCons z s) = 

if fz then StreamCons z (filter fs) else filter fs 
This definition is not guarded: in the then-case of the conditional, 
the recursive call to filter is not within an application of the stream 
constructor StreamCons. A syntactic guardedness checker is right 
to reject this definition: consider the case when all of the elements 
of the stream are filtered out; filter will never return anything, and 
so will be non-productive. 

Syntactic guardedness checkers are not always so helpful. The 
following higher-order function defines a general merge function 
on pairs of streams: 

merge f:: (Integer —> Integer —» Stream —> Stream) —> 
Stream — y Stream —y Stream 
merge/ f (StreamCons xxs) (StreamCons y ys) = 
fxy (mergeffxsys) 

Any syntactic checker looking for constructors to guard recursive 
calls will reject this function: there are no constructors anywhere 
in the definition! This rejection is with good reason: there are func¬ 
tions that we could pass to merge/ that would render it unproduc¬ 
tive. For example, this function will cause merge/ to hang on all 
pairs of streams: 

bad/\\ Integer — y Integer —» Stream — y Stream 
bad/x y s = s 

On the other hand, there are plenty of good functions/that we could 
use with merge/ to obtain productive functions, but a syntactic 
guardedness checker does not allow us to express this fact. 

A possible way out of this problem is to retain the syntactic 
guardedness check, and work around it by changing the type of /. 
For instance, we could change the required type of/to: 

/:: Integer — y Integer —y Integer 

to allow for merging functions that operate element-wise. Or we 
could change the type to 

/'.'. Integer — y Integer — y (Integer, [Integer]) 
which would allow for the functional argument to replace each pair 
of elements from the input streams with a non-empty list of values. 
The general trick is to make / return “instructions” on how to 
transform the stream back to merge/ which then executes them in a 
way that the syntactic guardedness checker can see is guarded. This 


technique has been elaborated in detail by Danielsson [8]. However, 
it is difficult to see whether we could capture all the possibilities 
for good/s in a single type. We could give yet another type which 
would accommodate the behaviour of the following possible value 

off 

fxys = StreamCons x (map (+y) s) 

Incorporating the forms of all the possible productive definitions 
into a single type seems impractical. Moreover, we complicate the 
definition of merge/, which is now forced to become essentially 
an implementation of a virtual machine for running little stream 
transformer programs returned by its functional argument, rather 
than the simple one line definition we gave above. 

A more promising type-based solution is provided by Nakano 
[20]. Nakano introduces a guardedness type constructor that repre¬ 
sents values that may only be used in a guarded way. Thus Nakano 
transports the guardedness checks from the syntactic level into the 
type system. We write this constructor, applied to a type A, as >A 
(Nakano uses the notation »A, but the >A notation has become 
more common, and conveys an intuitive idea of displacement in 
time). A useful way to think of >A is as a value of A that is only 
available “tomorrow”, and the temporal gap between today and to¬ 
morrow can only be bridged by the application of a constructor 
such as StreamCons. The reading of > A as a value of A tomorrow 
is explicitly supported in the step-indexed semantics we present in 
Section 3 by means of a clock counting down to zero. 

We now alter the type of/to he: 

/:: Integer —y Integer —y >Stream —y Stream 

This type captures the intuition that the stream argument to/must 
only be used in a guarded way. To introduce guarded types into the 
system, we must make some changes to the types of our primitives. 
We alter the type of the constructor StreamCons as follows, and 
also introduce a stream deconstructor that we previously implicitly 
used via pattern matching: 

StreamCons :: Integer -y >Stream — y Stream 
deStreamCons :: Stream — y (Integer, [>Stream) 

The type of StreamCons shows that it takes a guarded stream 
“tomorrow”, and produces a non-guarded stream “today”. This is in 
line with the temporal intuition we have of the type > Stream. The 
inverse operation deStreamCons takes a full stream and returns the 
integer and the guarded remainder of the stream. 

To give the guardedness type constructor force, Nakano pro¬ 
poses the following alternative type of the fixpoint operator for 
defining recursive values: 

fix :: (>A — y A) —y A 

(The standard typing of the fix operator is (A —y A) — y A.) 
Nakano’s alternative typing ensures that recursive definitions must 
be guarded by only allowing access to recursively generated values 
“tomorrow”. 

To actually program with the guardedness constructor, we equip 
it with the structure of an applicative functor [18]: 
pure :: A —y >A 
(®) :: >(A -y B) -y >A —y >B 

Note that > is not a monad: a join operation of type > (> A) —y >A 
would allow us to collapse multiple guardedness obligations. 

This method for integrating Nakano’s guardedness type con¬ 
structor into a typed A-calculus is not the only one. Nakano uses a 
system of subtyping with respect to the guardedness type construc¬ 
tor that has a similar effect to assuming that > is an applicative 
functor. We propose to treat > as an applicative functor here, due 
to the greater ease with which it can be incorporated into a standard 
functional programming language like Haskell. Krishnaswami and 


Benton [14, 15] have presented an alternative method that anno¬ 
tates members of the typing context with the level of guardedness 
that applies to them. Severi and de Vries [22] have generalised Kr- 
ishnaswami and Benton’s approach for any typed A-calculus de¬ 
rived from a Pure Type System (PTS), including dependently typed 
systems. These calculi have nice proof theoretic properties, such as 
being able to state productivity in terms of infinitary strong normal¬ 
isation. 

With the guardedness type constructor, and its applicative func¬ 
tor structure, we can rewrite the merge/ function to allow the alter¬ 
native typing which only allows functional arguments that will lead 
to productive definitions. 

merge/ :: (Integer —» Integer —»• > Stream —» Stream) —> 
Stream —> Stream —>• Stream 
merge// = fix (Ag xs ys. 

let (x,xs') = deStreamCons xs 
( y,ys') = deStreamCons y,s 
in/xy (g®xs' ®ys’)) 

Aside from the explicit uses of fix and deStreamCons, which 
were hidden by syntactic sugar in our previous definition, the only 
substantial changes to the definition are the uses of applicative 
functor apply (©). These uses indicate operations that are occurring 
under a guardedness type constructor. 

1.2 From the infinite to the finite 

The type system for guarded recursion that we described above al¬ 
lowed us to remove the syntactic guardedness check and replace it 
with a compositional type-based one. However, aside from propos¬ 
ing applicative functor structure as a convenient way to incorporate 
the guardedness type constructor into a functional language, we 
have not gone much beyond Nakano’s original system. We now de¬ 
scribe a problem with guarded recursion when attempting to com¬ 
bine infinite and finite data. We propose a solution to this problem 
in the next subsection. 

Consider the take function that reads a finite prefix of an infinite 
stream into a list. This function will have the following type: 

take :: Natural —>• Stream —> [Integer] 
where we wish to regard the type [Integer] as the type of finite fists 
of integers. The explicit segregation of well-founded and non-well- 
founded types is important for our intended applications of total 
functional programming and theorem proving. 

We also assume that the type Natural of natural numbers is well- 
founded, so we may attempt to write take by structural recursion on 
its first argument. However, we run into a difficulty, which we have 
highlighted . 

take :: Natural —> Stream —> [Integer] 
take 0 s = [] 

take (n + 1) s = x : take n s' 
where (x,s') = deStreamCons i 
The problem is that the variable s', which we have obtained 
from deStreamCons, has type > Stream. However, to invoke the 
take function structurally recursively, we need something of type 
Stream, without the guardedness restriction. 

We analyse this problem in terms of our intuitive reading of 
[>Stream as a stream that is available “tomorrow”. Nakano’s typing 
discipline slices the construction of infinite data like Stream into 
discrete steps. In contrast, a well-founded data type like [Integer] 
lives entirely in the moment. While a stream is being constructed, 
this slicing is required so that we do not get ahead of ourselves 
and attempt to build things today from things that wifi only be 
available tomorrow. But once a stream has been fully constructed, 
we ought to be able to blur the distinctions between the days of its 


construction. We accomplish this in our type system hy means of 
clock variables, and quantification over them. 

1.3 Clock variables 

We extend the type system with clock variables k. A clock variable 
k represents an individual time sequence that can be used for 
safe construction of infinite data like streams. In our model, clock 
variables are interpreted as counters running down to zero in the 
style of step-indexed models. By quantifying over all counters we 
are able to accommodate all possible finite observations on an 
infinite data structure. 

We annotate the guardedness type constructor with a clock vari¬ 
able to indicate which time stream we are considering: c £A. Infinite 
data types such as streams are now annotated by their clock vari¬ 
able, indicating the time stream that they are being constructed on. 
We have the following new types for the constructor and decon¬ 
structor: 

StreamCons" :: Integer —> t> Stream” —> Stream” 
deStreamCons” :: Stream” —> (Integer, t?Stream”) 

We now regard the type Stream” as the type of infinite streams 
in the process of construction. A finished infinite stream is repre¬ 
sented by quantifying over the relevant clock variable: Vac. Stream”. 
If we think of each possible downward counting counter that k 
could represent, then this universally quantified type allows for any 
counter large enough to allow us any finite extraction of data from 
the stream. We use the notation An.e and e[«] to indicate clock 
abstraction and application respectively, in the style of explicitly 
typed System F type abstraction and application. 

The fixpoint operator is parameterised by the clock variable: 

fix:: \/k.(&A^-A) A 
as is the applicative functor structure carried hy C>: 

pure :: V/t .A —► p ?A 

(©) :: V/t.c if (A — a S) — a t?A —y &B 

We also add an additional piece of structure to eliminate guarded 
types that have been universally quantified: 

force :: (V«. P>A) — > (Vk. A) 

Intuitively, if we have a value that, for any time stream, is one 
time step away, we simply instantiate it with a time stream that 
has at least one step left to run and extract the value. Note that the 
universal quantification is required on the right hand side since K 
may appear free in the type A. The force operator has a similar 
flavour to the runST :: (Vs.ST s a) —> a for the ST monad 
[16, 19]. In both cases, rank-2 quantification is used to prevent 
values from “leaking” out from the context in which it is safe to 

Using force we may write a deconstructor for completed 
streams of type Vk. Stream”. 

deStreamCons :: (V«.Stream”) —> (Integer, V«.Stream”) 
deStreamCons x = 

(AK.fst (deStreamCons” (*[«:])), 
force (Atc.snd (deStreamCons” (*[«])))) 

In this definition we have made use of a feature of our type system 
that states that the type equality Vac .A = A holds whenever k 
is not free in A. Our system also includes other type equalities 
that demonstrate how clock quantification interacts with other type 
formers. These are presented in Section 2.2. 

In the presence of clock variables, our definition of take is well- 
typed and we get the function we desire: taking a finite observation 


of a piece of infinite data: 

take :: Natural —>• (Wc.Stream*) —► [Integer] 
take 0 s = [] 

take (n + 1) s = x-. take n s' 

where (x,s') = deStreamCons s 
Clock variables also allow us to make clear in the types fine 
distinctions between functions that are extensionally equal, but dif¬ 
fer in their productivity. In plain Haskell, the following two stream 
mapping functions have the same behaviour on any completely con¬ 
structed stream. The first map processes each element one at a time 
map f s = StreamCons (/ x) (map f s') 
where (x, /) = deStreamCons s 
while maap processes elements two at a time by pattern matching: 
maap f (StreamCons x (StreamCons y s")) 

= StreamCons (/ a;) (StreamCons (/ y) ( maap f s")) 

If all the elements of the input are available at once, then map and 
maap have the same behaviour. However, if these functions are 
passed streams that are still being constructed, then their behaviour 
can differ significantly. Consider these two definitions of a stream 
of natural numbers, using map and maap : 

nats = StreamCons 0 (map (Ax. x + 1) nats) 
badnats = StreamCons 0 (maap (Ax. x + 1) badnats) 
Running nats produces the infinite stream of natural numbers, as 
expected, but running badnats produces nothing. The function 
maap expects two elements to be available on its input stream, 
while badnats has only provided one. 

Even though map and maap are extensionally equal, they have 
different behaviour on partially constructed streams. We can state 
this different behaviour using the following types in our system: 
map :: Vk.(I nteger —y Integer) —y Stream* —y Stream* 
maap :: (Integer —y Integer) — y (Vre.Stream*) —y (Vk.S tream*) 
Thus, map’s type states that the input stream and output stream run 
on the same clock k, so each element of the output will only require 
one element of the input. This is exactly what nats requires, and our 
type system will accept the definition of nats. In contrast, maap’ s 
type states that it requires a fully constructed stream as input. The 
definition of badnats does not provide this, and so our type system 
will reject it. 

By using clock quantification to “close over” the guardedness, 
our approach thus localises the discipline which makes the produc¬ 
tivity of definitions plain, without affecting the types at which the 
defined objects are used. Abel’s sized types impose a similar disci¬ 
pline, but globally [1]. 

1.4 Final coalgebras from initial algebras, guards and clocks 

In the previous subsection, we informally stated that the type 
Stream = V/t.Stream* represents exactly the type of infinite 
streams of integers. We make this informal claim precise by us¬ 
ing the category theoretic notion of final coalgebra. A key feature 
of our approach is that we decompose the notion of final coalgebra 
into three parts: initial algebras, Nakano-style guarded types, and 
clock quantification. 

Initial algebras In Section 2 we present a type system that in¬ 
cludes a notion of strictly positive type operator. We include a least 
fixpoint operator pX.F[X). For normal strictly positive type oper¬ 
ators F (i.e. ones that do not involve the t> operator), pX.F[X] is 
exactly the normal least fixpoint of F. Thus we can define the nor¬ 
mal well-founded types of natural numbers, lists, trees and so on. 
Our calculus contains constructors Cons F :: F[pX.F] —y pX.F 
for building values of these types, and recursion combinators for 


eliminating values: 

primRec F , A :: (F[(pX.F) x A] -y A) -y pX.F[X] -y A 
We opt to use primitive recursion instead of a fold operator (i.e. 
fold :: {F[A] — y A) —>■ pX.F[X] -y A) because it allows for 
constant time access to the top-level of an inductive data structure. 

We show in the proof of Theorem 2 that pX.F is the carrier of 
the initial F-algebra in our model. Therefore, we may use stan¬ 
dard reasoning techniques about initial algebras to reason about 
programs written using the primRec combinator. 

Guarded final coalgebras When we consider strictly positive 
type operators of the form F[pfX], where k does not appear in 
F then, in addition to pX.F[AX] being the least fixpoint of the 
operator F[c?—], it is also the greatest fixpoint. This initial-final 
coincidence is familiar from domain theoretic models of recursive 
types (see, e.g., Smyth and Plotkin [23]), and has previously been 
observed as a feature of guarded recursive types by Birkedal el 
al. [6], 

The unfold combinator that witnesses pX ,F[AX\ as final can 
be implemented in terms of the fix operator, and Cons: 

unfold F :: Vk.(A -y F[&A\) -y A-y pX.F[AX] 

unfold F = Ak.A/.Hx (Ag a.Cons (fmap F (A x.g © x) {fa))) 
where fmap F :: {A —y B) —y (F[A] —y F[B]) is the functorial 
mapping combinator associated with the strictly positive type oper¬ 
ator F. Note that without the additional A in F[t>—], there would 
be no way to define unfold, due to the typing of fix. 

To make observations on elements, we define a deConsF com¬ 
binator for every F, using the primitive recursion 

deConsF :: Vk.(/xXF[C?X]) -y F[ApX.F[AX)\ 
deConsF = Ak. primRec ( Xx.Jmap F [>«_] (Ay.fsty) x) 

The proof of Theorem 3 shows that these definitions of unfoldF and 
deConsF exhibit pX.F[AX] as the final F[A-]- coalgebra, using 
deConsF as the structure map. This means that unfoldi.- [k]J is the 
unique F[A— ]-coalgebra homomorphism from A to pX.F[A—]. 
Final coalgebras Theorem 3 only gives us final coalgebras in 
the case when the recursion in the type is guarded by the type 
constructor A —. So we do not yet have a dual to the least fixpoint 
type constructor pX.F. However, as we hinted above in the case 
of streams, we can use clock quantification to construct a final F- 
coalgebra, where F need not contain an occurrence of C> —. 

For the type Vk./ F X'.F[e?— ] we define an unfold",- operator, 
in a similar style to the unfoldF operator above. However, this 
operator takes an argument of type (A —y F[A]), with no mention 
of guardedness. 

unfoldp :: (A -y F[A]) -y A-y \/n.pX.F[AX] 
unfoldf = Xfa.An. 

fix (A g a.ConsF (fmap F {Xx.g © pure x) (fa))) a 
We can also define the corresponding deconstructor, building on 
the definition of deConsF above, but also using the force construct 
in conjunction with clock quantification. This is a generalisation of 
the definition of deStreamCons above. 
deConsf :: (\/K.pX.F[AX]) -y F[V/t./iX.F[^X]] 
deConsf = Ax. fmapF (Ax.force x) (Ak. deConsF [«] (x[k])) 
In the application of fmapF, we make use of the type equalities 
in our calculus, which allow us to treat the types V/t.F[X] and 
F[V/t.X] as equivalent, when k does not appear in F. We present 
the type equalities in Section 2.2, and prove them sound in Sec- 

Our last main technical result. Theorem 4, states that, in the 
semantics we define Section 3, V/t./rX.F[c?—] actually is the final 
F-coalgebra. The use of clock quantification has allowed us to 


A; 0 b 1 : type 


remove mention of the guardedness type constructor, and given us 
a way to safely program and reason about F-coalgebras. 

1.5 Circular traversals of trees 

We now present a perhaps unexpected application of the use of 
clock quantification that does not relate to ensuring productivity of 
recursive programs generating infinite data. An interesting use of 
laziness in functional programming languages is to perform single¬ 
pass transformations of data structures that would appear to require 
at least two passes. A classic example, due to Bird [3], is the 
replaceMin function that replaces each value in a binary tree with 
the minimum of all the values in the tree, in a single pass. In normal 
Haskell, this function is written as follows: 
replaceMin :: Tree —> Tree 

replaceMin t = let (l' ,m) = replaceMinBody t m in t' 

replaceMinBody (Leaf x) m = (Leaf m,x) 
replaceMinBody (Br l r) m = 

let (/'. mi) = replaceMinBody l m 
(/,m r ) = replaceMinBody rm 
in(Br/V, minmimr) 

The interesting part of this function is the first let expression. This 
takes the minimum value m computed by the traversal of the tree 
and passes it into the same traversal to build the new tree. This 
function is a marvel of declarative programming: we have declared 
that we wish the tree t' to be labelled with the minimum value in 
the tree t just by stating that they be the same, without explaining 
at all why this definition makes any sense. Intuitively, the reason 
that this works is that the overall minimum value is never used in 
the computation of the minimum, only the construction of the new 
tree. The computation of the minimum and the construction of the 
new tree conceptually exist at different moments in time, and it is 
only safe to treat them the same after both have finished. 

Using explicit clock variables we can give a version of the 
replaceMin definition that demonstrates that we have actually de¬ 
fined a total function from trees to trees. The use of clock variables 
allows us to be explicit about the time when various operations are 
taking place. 

Out first step is to replace the circular use of let with a feedback 
combinator defined in terms of the fix operator: 
feedback : V«. (c W -A (B[k],U)) -a B[k] 
feedback = A/t.A/.fst (fix (Xx. f (pure (Ax.snd x) © x))) 

In the application of the fix operator, x : t£(B x U). The notation 
B [k] indicates that k may appear free in the type B. 

We now rewrite the replaceMinBody function so that we can 
apply feedback to it. We have highlighted the changes from the 
previous definition. 

replaceMinBody :: Tree —> 1 /k. Integer -» ( t? Tree, Integer) 

replaceMinBody (Leaf*) m = ( pure Leaf® m,x) 
replaceMinBody (Br l r) m = 

let (l', mi) = replaceMinBody l m 
(r',m r ) = replaceMinBody rm 
in ( pure Br © l' fif/-'. min mi m r ) 

The changes required are minor: we must change the type, and use 
the applicative functor structure of t? to indicate when computa¬ 
tions are taking place “tomorrow”. 

Applying feedback to replaceMinBody, and using force to re¬ 
move the now redundant occurrence of c?, we can define the full 
replaceMin function in our system: 
replaceMin :: Tree —> Tree 

replaceMin t = force (An.feedback{n] (replaceMinBody[ k]) t) 
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Figure 1. Well-formed types and type operators 

By the soundness property of our system that we prove in Section 3, 
we are assured that we have defined a total function from trees 
to trees. The standard Haskell type system does not provide this 
guarantee. 

1.6 Models of guarded recursion 

To substantiate the claims we have made in this introduction, in 
Section 3 we construct a multiply-step-indexed model of the type 
system we present in the next section. The multiple step-indexes 
are required for the multiple clock variables in our system, each 
representing separate time streams. Step-indexed models were in¬ 
troduced by Appel and McAllester [2] to prove properties of recur¬ 
sive types. The use of step-indexing serves to break the circularity 
inherent in recursive types. Dreyer et al. [10] exposed the connec¬ 
tion between Nakano’s guarded recursion and step indexed models. 
More recently, Birkedal et al. [4, 6] have elaborated this connec¬ 
tion, particularly in the direction of dependent types. 

Alternative semantics for guarded recursion have involved ul¬ 
trametric spaces, for example Birkedal et al. [5] and Krishnaswami 
and Benton [15]. Hutton and Jaskelioff [13] have also used an ap¬ 
proach based on metric spaces for identifying productive stream 
generating functions. 

Finally, we mention the syntactic approach of Severi and de 
Vries [22], who define the notion of infinitary strong normalisa¬ 
tion to prove productivity of dependent type systems with guarded 
recursion. 

2. A type system with clocks and guards 

In the introduction, we presented our motivating examples in terms 
of a Haskell-like language informally extended with a Nakano-style 
guard modality and clock quantification. To formally state the prop¬ 
erties of our combination of clock quantification, clock-indexed 
guard modalities and inductive types, in this section we define an 
extension of the simply-typed A-calculus with these features. In the 
next section, we define a semantics for our system in which we can 
formally state the results that we claimed in the introduction. 

2.1 Well-formed types with clock variables 

The types of our system include two kinds of variable that may 
occur free and bound: clock variables in the clock quantifier and the 
clock-indexed guard modality, as well as type variables occurring 












in strictly positive positions for the inductive types. We therefore 
formally define when a type is well-formed with respect to contexts 
of clock and type variables, using the rules displayed in Figure 1 . 

The well-formedness judgement for types (A; ©hi: type) 
is defined with respect to a clock context A and a type variable con¬ 
text 0. Clock contexts are lists of clock variables, A = ki, k„, 
and type variable contexts are lists of type variable names, 0 = 
Xi,X„. Type variables are only used to manage the scope of 
the nested least fixpoint type operator //; there is no type polymor¬ 
phism in the type system we present here. We generally use Roman 
letters A, B, C to stand for types, but we also occasionally use F 
and G when we wish to emphasise that types with free type vari¬ 
ables are strictly positive type operators. For any type A, we define 
fc(A) to be the set of free clock variables that appear in A. 

Most of the type well-formedness rules are standard: we have 
a rule for forming a type from a type variable that is in scope 
and rules for forming the unit type 1, product types A X B, sum 
types A + B, function types A —y B and least fixpoint types 
pX.A. We enforce the restriction to strictly positive type operators 
by disallowing occurrences of free type variables in the domain 
component of function types. In Section 2.3, we will see that each 
of the standard type constructors will have the usual corresponding 
term-level constructs; our system subsumes the simply typed A- 
calculus with products, sums and least fixpoint types. 

The remaining two rules are for forming clock quantification 
Vk.A types and the clock-indexed Nakano-style guard modality 
C? A. The type formation rule for clock quantification is very similar 
to universal type quantification from standard polymorphic type 
theories like System F. 

As we described in the introduction in Section 1.3, we have 
augmented the Nakano-style delay modality with a clock variable. 
This allows us to distinguish between guardedness with respect to 
multiple clocks, and hence to be able to close over all the steps 
guarded by a particular clock. 

2.2 Type Equality 

The examples we presented in the introduction made use of several 
type equalities allowing us to move clock quantification through 
types. For instance, in the definition of the deStreamCons stream 
deconstructor in Section 1.3, we made use of a type equality to treat 
a value of type Vk. Integer as having the type Integer. Intuitively, 
this is valid because a value of type Integer exists independently 
of any clock, therefore we can remove the clock quantification. 
In general, clock quantification commutes with almost all strictly 
positive type formers, except for guards indexed by the same clock 
variable. For those, we must use force. 

The following rules are intended to be read as defining a judge¬ 
ment A; 0 I - A = B : type, indicating that the well-formed types 
A; 0 h A : type and A; © b B : type are to be considered 
equal. In addition to these rules, the relation Ah A = B : type is 
reflexive, symmetric, transitive and a congruence. 


Vk.A 

= 

A 

(k0/c(A)) 

Vk.A -(- B 

= 

(Vk.A) + (Vk.B) 


Vk.A x B 

= 

(Vk.A) x (Vk.B) 


Vk.A ->■ B 

= 

A -*• Vk.B 

(k*/c(A)) 

Vk.Vk'.A 

= 

Vk'.Vk.A 

(«*«') 

Vk.^'A 

= 

C^'Vk.A 

(k i= k') 

Vk./xX.F[A, X] 

= 

pX.F\VK.A, X] 

(/c(F)=0) 


In the last rule, F must be strictly positive in A as well as X. 

After we define the terms of our system in the next sub-section, 
it will become apparent that several of the type equality rules 
could be removed, and their use replaced by terms witnessing the 
conversions back and forth. In the case of product types, we could 
define the following pair of terms (using the syntax and typing rules 


we define below): 

Ax.(A«.fst (:e[k]), Afc.snd (*[«;])) 

: (Vk.A x B) -y (Vk.A) x (Vk.B) 

Aa.A«;.(fst x [k], snd x [«]) 

: (Vk.A) x (Vk.B) -+ Vk.A x B 
Indeed, the denotational semantics we present in Section 3 will 
interpret both of these functions as the identity. However, not all 
the type equality rules are expressible in terms of clock abstraction 
and application, for instance, the Vk.A = A rule and the rule 
for sum types. Moreover, our definition of deCons in Section 1.4 
is greatly simplified by having clock quantification commute with 
all type formers uniformly (recall that we made crucial use of the 
equality Vk.F[—] = F[Vk.—]). Therefore, we elect to include type 
equalities for commuting clock quantification with all type formers 
uniformly. 

2.3 Well-typed Terms 

The terms of our system are defined by the following grammar: 
e, f, g ::= x \ * \ Xx. e \ fe | (ei, e 2 ) | fst e | snd e 
| ini e | inr e | case e of ini x.f\ inr y.g 
j ConsF e | primRecp e | An.e | e[«'] 
j pure x | / © e | fix / | force e 

The well-typed terms of our system are defined by the typing 
judgement A; F h e : A, given by the rules presented in Figure 2. 
Terms are judged to be well-typed with respect to a clock variable 
context A, and a typing context F consisting of a list of variable : 
type pairs: xi : A],.... x„ : A n . We only consider typing contexts 
where each type is well-formed with respect to the clock variable 
context A, and the empty type variable context. The result type A 
in the typing judgement must also be well-formed with respect to 
A and the empty type variable context. 

We have split the typing rules in Figure 2 into five groups. 
The first group includes the standard typing rules for the simply- 
typed A-calculus with unit, product and sum types. Apart from 
the additional clock variable contexts A, these rules are entirely 
standard. The second group contains the rules for the inductive 
types pX.F. Again, apart from the appearance of clock variable 
contexts, these rules are the standard constructor and primitive 
recursion constructs for inductive types. 

The third group of rules cover clock abstraction and application, 
and the integration of the type equality rules we defined in the 
previous section. In the k-App rule, we have used the notation 
A[k k'] to indicate the substitution of the clock variable k! 
for k. These rules are as one might expect for System F-style 
quantification with non-trivial type equality, albeit that in the k-App 
rule the k' clock variable cannot already appear in the type. This 
disallows us from using the same clock variable twice, preventing 
multiple “time-streams” becoming conflated. 

The fourth group of rules state that the clock-indexed guard 
modality supports the pure and apply (®) operations of an applica¬ 
tive functor. When we define a denotational semantics of our calcu¬ 
lus in the next section, these operations will be interpreted simply as 
the identity function and normal function application respectively, 
meaning that the applicative functor laws hold trivially. 

Finally, the fifth group of rules presents the typing for Nakano’s 
guarded fix combinator, now indexed by a clock variable, and 
our force combinator for removing the guard modality when it is 
protected by a clock quantification. 

2.4 Type operators are functorial 

In Section 1.4 we used a functorial mapping function finap F : 
(A —> B) —> F[A] -y F[B], which we claimed was defined 
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A-T,x :A\-e:B 


A ; r\-x-.A y > A ; rh* : r 

A: T b ei : A A ; rbe 2 :B 

A; r b (ei,e 2 ) : A x B (PAIR) 

A;T b e : B 

A- T b inr e ■ A + B (lNR) 


A; T b Ax e : A —>■ B 


A;T b e : A x B 


A; T b e : A x B 


A ; rb/e:B 

A; r b e 


A; r b fst e : A ' ° > A ; rbsnde:B v ' A; F b ini e : A + B v 

A; T b e : A + B A ; r,x:Ab/:C A; T,y : B b g : C 
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A; r b ConsF e : pX.F[X] ( 


2. Least Fixpoint Types 

A; r b e : F[(uX.F[X]) X A] -f A 
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A; r b primRecF e : pX.F[X] A 


A; r b A/t.e : V«.A 


3. Clock Abstraction and Application, and Type Equality 

k £ /c(T) , A; r b e : Vk.A k e A n't /c(A) 
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- (K-ABS) 

A; r b e 


Ab A = B 


- (TyEq) 
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A; T b pure e : E> A 


A; r b / : C> (A —» B) A; r b e : C> A 
A ; rb/@e:t>B ( 


A ; rb/:>M^A 


5. Fix and Force 

A; T b e : V/t.E> A 

] ‘ A; T b force e : Vk.A ^ 

Figure 2. Well-typed terms 


fmap F : 

:(A^ 

-4 F[l] F0] 


finapx. 

fx = 

fiX 


finap 1 

fx = 

* 


finap Fy< 

G f x = 

( fmap F f (fst x),fmap G 

f (snd x)) 

finaPp+a f x = 

case x of ini y. ini (finap 

f fy) 



inr z.inr (fmap G f z) 

finap A ^ F fx = 

Xa. finap F f (x a) 


fmap ]>r , 

F f x = 

pure (fmapp f) © x 


finap\t K , 

pf x = 

An.finapp f (s[k]) 


finaPy.x 

,pf x = 

primRec ( Xx.Cons(jmap 

F f (Xx. snd x) x)) 


Figure 3. ftnap F for all type operators F 


for each strictly positive type operator F. We define this operator 
by structural recursion on the derivation of F, using the clauses in 
Figure 3. Due to the presence of nested least fixpoint types in our 
calculus, we handle n-ary strictly positive type operators. 

2.5 Programming with guarded types and clocks 
Lists and Trees, Finite and Infinite Using the least fixpoint 
type operator /iX.F, we can reconstruct many of the usual in¬ 
ductive data types used in functional programming. For example, 


the OCaml declaration: 

type list = NilList | ConsList of A x list 

of finite lists of values of type A, can be expressed as the type 
fiX.l + A x X in our system, where we have replaced the two 
constructors NilList and ConsList with a use of the sum type 
former. Likewise, the type of binary trees labelled with As that we 
used in Section 1.5 can be written as pX.A + X x X. 

A similar data type declaration in Haskell has a different inter¬ 
pretation. If we make the following declaration in Haskell: 

data List = NilList | ConsList A List 

then the type List includes both finite lists of As, and infinite 
lists of As (a similar effect can be achieved in OCaml by use of 
the lazy type constructor). Haskell’s type system is too weak to 
distinguish the definitely finite from the possibly infinite case, and it 
is often left to the documentation to warn the programmer that some 
functions will be non-productive on infinite lists (for example, the 
reverse function). 

Making use of Nakano’s guard modality E> —, we are able to 
express Haskell-style possibly infinite lists as the guarded inductive 
type /JjX. 1 + A x C> A. As we saw in the introduction, infinite lists 
can be constructed using the guarded fix operator. For example, the 
infinite repetition of a fixed value can be written in our system as: 

Aa.fix (AZ.Cons (inr (a, l))) 























If we restrict ourselves to only one clock variable, and always use 
guarded recursive types, then we obtain a programming language 
similar to a monomorphic Haskell, except with a guarantee that all 
functions are productive. 

Co-inductive Streams As we saw in Section 1.2, programming 
with guarded types is productive, but they are fundamentally in¬ 
compatible with normal inductive types. Recall that if we define 
infinite streams of As as Stream' 4 A = pX.A x t>X, then there is 
no way of defining a function tail : Stream” A — y Stream” A; the 
best we can do is tail : Stream” A —y t? Stream” A. The rest of the 
stream only exists “tomorrow”. 

Clock quantification fixes this problem. We define: 

Stream A = Mn.pX.A x A 

Now we can define the two deconstructors for making observations 

on streams, with the right types: 

head : Stream A —>• A 

head = As.A/t. prim Rec (Ax.fst x) (.s[/tj) 

tail : Stream A —»• Stream A 

tail = As.(force (Arc. primRec (Ao;.pure(Ax.fst x) © (sndrr)) 

(»[«]))) 

In the definition of head we use the fact that k cannot appear in A 
to apply the first type equality rule from Section 2.2. 

Stream Processing Ghani, Hancock and Pattinson [11] define a 
type of representations of continuous functions on streams using a 
least fixpoint type nested within a greatest fixpoint. A continuous 
function on streams is a function that only requires a finite amount 
of input for each element of the output. Ghani et al.’s type is 
expressed in our system as follows: 

SP I O = \/n.pX.p,Y.(I -yY) + (Ox >”X) 

where SP stands for “Stream Processor” and I and O stand for input 
and output respectively. In this type, the outer fixpoint permits the 
production of infinitely many Os, due to the guarded occurrence 
of X, while the inner fixpoint only permits a finite amount of 7s 
to be read from the input stream. This kind of nested fixpoint is 
not expressible within Coq, but is possible with Agda’s support for 
coinductive types [9]. 

Defining the application of an SP 7 O to a stream of 7s serves as 
an interesting example of programming with guards and clocks. We 
make use of a helper function for unfolding values of type SP 7 O 
that have already been instantiated with some clock: 

Step : SP K IO —y pY.(I -y Y) x (O x c >(SP K I O )) 

where SP K I O is SP I O instantiated with the clock k. 

The definition of stream processor application goes as follows, 
where we permit ourselves a little pattern matching syntactic sugar 
for pairs: 

apply : SP 7 O —>• Stream 7 —► Stream O 
apply = 

Xsp s.AK.Sx(Xrec sp s. 

primRec (Xx s.case x of 

ini/. / (head s) (tail s ) 
inr (o,sp’). 

Cons(o, rec © sp’ © pure s)) 

(step sp)) 

(sp [«]) s 

This function consists of two nested loops. The outer loop, ex¬ 
pressed using fix, generates the output stream. This loop is running 
on the clock re, introduced by the Arc. We have instantiated the 
stream processor with the same clock; this causes the steps of the 


output stream to be in lockstep with the output steps of the stream 
processor, exactly as we might expect. The inner loop, expressed 
using primRec, recurses over the finite list of input instructions 
from the stream processor, pulling items from the input stream as 
needed. The input stream is not instantiated with the same clock as 
the stream processor and the output stream: we need to access an 
arbitrary number of elements from the input stream for each step of 
the stream processor, so their clocks cannot run in lockstep. 

The Partiality Monad The partiality monad is a well-known 
coinductively defined monad that allows the definition of func¬ 
tions via general recursion, even in a total language. The partiality 
monad is defined as Partial A = i/X.A+X. Hence, a value of type 
Partial A consists of a stream of inrs, either continuing forever, or 
terminating in an ini with a value of type A. Using the partiality 
monad, possibly non-terminating computations can be represented, 
with non-termination represented by an infinite stream that never 
returns a value. Capretta [7] gives a detailed description. 

To express the partiality monad in our system, we decompose it 
into a guarded least fixpoint and clock quantification, just as we did 
for streams and stream processors above: 

Partial” A = pX.A + E?X 
Partial A = Vrc.Partial” A 

For convenience, we define two constructors for Partial” A, corre¬ 
sponding to the two components of the sum type: 
now” : A -y Partial” A 
now” = A a. Cons (ini a) 

later ” : t? (Partial” A) — y Partial” A 
late A" = Xp. Cons (inr p) 

It is straightforward to use guarded recursion and clock quantifi¬ 
cation to define the return and bind functions that demonstrate 
that Partial is indeed a monad. For an example of a possibly non¬ 
terminating function that can be expressed using the partiality 
monad, we define the following function collatz. For each natu¬ 
ral number n, this function only terminates if the Collatz sequence 
starting from n reaches 1. Whether or not this sequence reaches 1 
for all n is a famous unsolved question in number theory. 
collatz : Natural —y Partial 1 

collatz = An.A/-,-.fix (A rec n.ii n = 1 then now” (*) 
else if n mod 2 = 0 then 
later ” (rec © (pure (n/2))) 
else 

later ” (rec © (pure (3 *n + 1)))) n 
The partiality monad is not a drop-in replacement for general 
recursion. The type Partial A reveals information about the number 
of steps that it takes to compute a value of type A. Therefore, it is 
possible to write a timeout function that runs a partial computation 
for a fixed number of steps before giving up: 

timeout : Natural —)• Partial A —r A + 1 
The partiality monad allows us to write possibly non-terminating 
functions, but also allows us to make more observations on them. 

3. A denotational semantics for clocks and guards 

We have claimed that the typing discipline from the previous sec¬ 
tion guarantees that programs will be productive. We now substan¬ 
tiate this claim by defining a domain-theoretic model of our sys¬ 
tem, and showing that the denotation of a well-typed closed term 
is never _L. We accomplish this by using a multiply-step-indexed 
interpretation of types, where the multiple step indexes correspond 
to the multiple clock variables that may be in scope. 
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Figure 4. Semantics for the simply-typed portion of our system 


3.1 Semantics of terms 

We interpret terms in (a mild extension of) the standard domain the¬ 
oretic model of the untyped lazy A-calculus, described by Pitts [21]. 
A feature of this semantics is the erasure of anything to do with the 
guardedness type constructor t?— and the clock quantification. The 
fix operator is interpreted as the domain-theoretic fixpoint, i.e., ex¬ 
actly the usual interpretation of general recursion. 

We assume a directed complete partial order with bottom 
(DCPOx), D, satisfying the following recursive domain equation: 

D = (D —¥ D)± ® {D x D)± ® D± ® D± ® lx 
where ® represents the coalesced sum that identifies the _L element 
of all the components. We are guaranteed to be able to obtain such a 
D by standard results about the category DCPOx (see, e.g., Smyth 
and Plotkin [23]). The five components of the right hand side of this 
equation will be used to carry functions, products, the left and right 
injections for sum types and the unit value respectively. We use 
the following symbols to represent the corresponding continuous 
injective maps into D: 

Lam : {D -A D) -A D Pair : D x D -A D 
Ini :D^D Inr : D^D 

Unit : 1 -A D 


We will write Unit instead of Unit *. 

Let V be the set of all possible term-level variable names. 
Environments 77 are modelled as maps from V to elements of 
D. Terms are interpreted as continuous maps from environments 
to elements of D. The clauses for defining the interpretation of 
parts of our system that are just the simply-typed A-calculus are 
standard, and displayed in Figure 4. It can be easily checked that 
this collection of equations defines a continuous function [—] : 
(V —> D) —} D, since everything is built from standard parts. 

The applicative functor structure for the guard modality is inter¬ 
preted just as the identity function and normal application, as we 
promised in Section 2.3: 


[pure e]77 
[/ ® e]7? 


Mb 

f df ([e]b) if [/]b = Lam df 
1 _L otherwise 


Our interpretation simply translates the fix operator as the usual fix- 
point operator fix / = |_| / n (_L) in DCPOx - The force operator 


fmapx / x 
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Figure 5. Semantic fmapF for A; 0 h F : type 


is interpreted as a no-operation. 

Ilfixfllr) = / fcdf if lfh= Lam d f 
H Ji 7 ) \ £ otherwise 

[force e]77 = [e^ 

Finally, we interpret the constructor Consj? and primitive recur¬ 
sion eliminator primRec/ for least fixpoint types. The interpreta¬ 
tion of construction is straightforward: the constructor itself disap¬ 
pears at runtime, so the interpretation simply ignores it: 

[ConsF ej?7 - [ej?7 

To define the semantic counterpart of the primRecx operator, 
we first define a higher-order continuous function primrec :(D—t 
D —^ D) —f (D —> D) —>• D in the model. This is very similar to 
how one would define a generic primRecF in Haskell using general 
recursion, albeit here in an untyped fashion, 
primrec fmap f = 

Lam (fix (A gx. f {fmap (Lam (AaxPair {x,gx)))) x)) 
The first argument to primrec is intended to specify a functorial 
mapping function. For each of the syntactic types A;0hT : type 
defined in Figure 1, we define a suitable fmapF : Dl°l — > D —> 
D, where |0| is the number of type variables in 0. This definition 
is presented in Figure 5. 

With these definitions we can define the interpretation of the 
syntactic prim Recx- operator. Note that the syntactic type construc¬ 
tor F here always has exactly one free type variable, so fmapF has 
type D —^ D —» D, as required by primrec. 

[primRecF /J?7 = 

{ primrec fmapF df if [y] 77 = Lam df 
_L otherwise 

This completes the interpretation of the terms of our program¬ 
ming language in our untyped model. We now turn to the semantic 
meaning of types, with the aim of showing, in Section 3.5, that each 
well-typed term’s interpretation is semantically well-typed. 

3.2 Interpretation of clock variables 

For a clock context A, we define [A] to be the set of clock envi¬ 
ronments: mappings from the clock variables in A to the natural 
numbers. We use 5, S' etc. to range over clock environments. For 
8 and S' in [A], we say that <5 C S' (in [A]) if for all k €E A, 




8(k) < S'(k). The intended interpretation of some 5 £ [A] is that 
8 maps each clock k in A to a natural number stating how much 
time that clock has left to run. The ordering <5 C S' indicates that 
the clocks in 5 have at most as much time left as the clocks in 8'. 
We use the notation 8[k n] to denote the clock environment 
mapping k to n and n' to S(k') when k k 1 . 


there is time remaining, then c? A equates a pair iff A would with 
one fewer steps remaining. For Kripke monotonicity, we want to 
prove that ( d, d!) £ (c?A)<5 implies (d, d ') £ A)8' when 8' C 

<5. If 8' (k) = 0 then {&A)8' = D x D 9 {d, d'). If 8' (k) = n' +1 
then 8{n) = n+1 with n' < n. So (d, d') £ A(<5[k n]), and so 

by A’s Kripke monotonicity, (d, d') £ A{8 '[k i-»- » ; ]) = (t^A)#'. 


3.3 Semantic types 

We interpret types as JA] -indexed families of partial equivalence 
relations (PERs) over the semantic domain D. Recall that a PER on 
D is a binary relation on D that is symmetric and transitive, but not 
necessarily reflexive. Since PERs are binary relations, we will treat 
them as special subsets of the cartesian product D x D. We write 
PER(D) for the set of all partial equivalence relations on D, and 
T d for the PER D x D. We require that our J A]-indexed families 
of PERs contravariantly respect the partial ordering on elements of 
[A], This ensures that, as the time left to run on clocks increases, 
the semantic type becomes ever more precise. When we interpret 
clock quantification as intersection over all approximations, we 
capture the common core of all the approximations. 

Formally, a semantic type for a clock context A is a function A : 
[A] —»• PER(D), satisfying contravariant Kripke monotonicity: 
for all 8' C 5, A5 C AS'. We write ClkPER(A) for the collection 
of all semantic types for the clock context A. In Section 4, we will 
formally consider morphisms between semantic types, and so turn 
each ClkPER( A) into a category. Note that we do not require that 
any of our PERs are admissible. Admissible PERs always include 
the pair (..L,precisely the values we wish to exclude. 

We now define semantic counterparts for each of the syntactic 
type constructors we presented in Section 2.1. 

Unit, Product, Coproduct and Function Types The construc¬ 
tions for unit, product and coproduct types are straightforward. The 
unit type will be interpreted by a constant family of PERs: 

15 = {(Unit, Unit)} 


This trivially satisfies Kripke monotonicity. 

Given semantic types A and B, their product is defined to be 


(A x B)5 = 


(Pair(a:, y), Pair(x', y 1 )) 

| (x, x’) £ |AJ5 A (y, y') 6 JBJ5 . 


and their coproduct is 
(A + B)8 = 


{(lnl(a;), lnl(*')) | ( x,x ') £ [A]|<5} 
{(lnr(y), lnr(j/)) | (y,y r ) £ [R]5} 


Since A and B are assumed to be semantic types, it immediately 
follows that Ax B and A + B are semantic types. 

To interpret function types, we use the usual definition for 
Kripke-indexed logical relations, by quantifying over all smaller 
clock environments. Given semantic types A and B, we define: 


(A -}• B)8 = 


(Lam(/), Lam(/')) 

| W C 8, (x, x') £ A8’. ( fx, fx') £ B8' 


It follows by the standard argument for Kripke logical relations that 
this family of PERs is contravariant in clock environments. 


Guarded Modality Given a semantic type A, we define the se¬ 
mantic guard modality E> as follows, where k is a member of the 
clock context A: 

(c?A)5-J TiP if 5(k) = 0 

A ^ K ^ n j) *(«)„* + ! 

The semantic type operator c>' acts differently depending on the 
time remaining on the clock k in the current clock environment 8. 
When the clock has run to zero, t>A becomes completely uninfor¬ 
mative, equating all pairs of elements in the semantic domain D. If 


Clock Quantification The semantic counterpart of clock quantifi¬ 
cation takes us from semantic types in ClkPER(A, k) to semantic 
types in ClkPER(A). Given a semantic type A in ClkPER(A, n), 
we define 

V„A = f| A(% h+ n]) 

n€N 

For Kripke monotonicity, if (d, d') £ ( Vk.A)8 then Vn. (d, d') £ 
A(5[k n]). Since A is a semantic type, Vn. (d, d') £ A(8 '[k h-> 

n]), hence (d, d') £ ( \/k.A)8'. 

Complete Lattice Structure In order to define the semantic coun¬ 
terpart of the least fixpoint type operator, we make use of the lat¬ 
tice structure of ClkPER(A). Given A,B£ ClkPER(A), we 
define a partial order: A C B if V5.A5 C B8. It is easy to see 
that ClkPER(A) is closed under arbitrary intersections, and so is 
a complete lattice. 

Each of the semantic type constructors above is monotonic 
with respect to the partial order on ClkPER(A) (with the obvious 
proviso that A —¥ B is only monotonic in its second argument). 

Least Fixpoint Types We make use of the Knaster-Tarski the¬ 
orem [24] to produce the least fixpoint of a monotone function 
on ClkPER(A). See Loader [17] for an similar usage in a set¬ 
ting without guarded recursion. Given a monotone function F : 
ClkPER(A) ->■ ClkPER(A), we define: 

(pF) = P|{A £ ClkPER(A) | FA C A} 

For any monotone F, pF is immediately a semantic type by con¬ 
struction, since semantic types are closed under intersection. As 
an initial step towards semantic type soundness for our calculus, 
we demonstrate a semantic well-typedness result for the primrec 
function we defined in Section 3.1. 

Lemma 1. Let F : ClkPER(A) —> ClkPER(A) be a monotone 
function. Let fmap : D —yD—t D be such that for all 8 £ [A], 
for all A, B £ ClkPER(A), and for all (g, g') £ (A —>■ B)8 and 
{x,x ') £ FAS, we have (fmap g x, fmap g' x') £ FB8. Then, 
for all 8 £ |AJ and for all (/, /') £ {F(pF xC)q C)8, where 
C is a semantic type, we have 

(primrec fmap /, primrec fmap f) £ (pF — C)5 

Proof. (Sketch) By induction on the least fixpoint F(pF) = pF, 
using the Knaster-Tarski theorem. □ 

This lemma only states that our semantic primrec recursion 
operator is semantically well-typed. We will show in Theorem 2 
that primrec also witnesses pF as the carrier of the initial F- 
algebra, as we claimed in Section 1.4. 

3.4 Interpretation of syntactic types 

A well-formed type A; 0 h A : type is interpreted as mono¬ 
tonic function [A] : ClkPER(A) |e| ClkPER(A), where |0| 
denotes the number of type variables in 0. The interpretation is de¬ 
fined in the clauses in Figure 6 . These clauses make use of the con¬ 
structions of semantic types defined in the previous subsection. In 
the clause for Vk, we make use of the “clock weakening” operator 
—t/s which takes a collection of semantic types in ClkPER(A)' e 
to semantic types in ClkPER(A, /i{ e by pointwise restriction of 
clock environments in [A, /t] to clock environments in [A]. 


[1]0 W. 

1 

ix\9 = 

9(X) 

[ AxBje = 

IA]0 x {B]0 

{A + Bj9 = 

IA}9 + IB}9 

lA^BjO = 

[A]0 -4 {B]0 

[c^Aje = 


[Vk.A]0 = 


ipx.Fje = 

p(AX.[Fj(0,X)) 


Figure 6. Interpretation of well-formed types 


The next lemma states that syntactic substitution and semantic 
substitution commute. The proof is a straightforward induction on 
the well-formed type A. Note the side condition that k 0 fc(A'), 
matching the side condition on the k-App typing rule. 

Lemma 2. Assume that A; 0 I- A : type, k, k' £ A and k' g 
fc(A). Then for all 5 £ [A[k i-4 «']J and 9 £ ClkPER(A) 1 ® 1 , 
IAJ0(6[k S(k')]) = IA[k K']](e[K ^ «']) 5 . 

The syntactic type equality judgement A; 0 I - A = B : type 
that we defined in Section 2.2 is interpreted as equality of semantic 
types. The following lemma states that this interpretation is sound. 
Lemma 3. If A; 0 h A = B : type then for all 9 £ 
ClkPER(A)l®l, [AJ0 = §B]0. 

The next lemma states that we may use the semantic fmapF 
functions defined in Figure 5 with the primrec operator, by show¬ 
ing that fmapF always satisfies the hypotheses of Lemma 1 . 
Lemma 4. For all A; 0 h F : type, the fmap F defined in 
Figure 5 are all semantically well-typed: For all 5 £ |AJ, for 
all JTfi £ ClkPER(A), and for all (g, g') £ {A -4 B)S and 
(x, x') £ FAS, we have (fmapF ~c[ x, fmapF x') 6 FBS. 

It may seem that we could prove this lemma by using the syn¬ 
tactic definition oifinap from Figure 3 and then applying Theorem 
1. However, the semantic well-typedness of our interpretation of 
primRec depends on the semantic well-typedness of fmap, so we 
must prove this lemma directly in the model to break the circularity. 

3.5 Semantic type soundness 

We now state our first main result: the semantic type soundness 
property of our system. To state this result, we define the semantic 
interpretation of contexts as a clock-environment indexed collec¬ 
tion of PERs over environments: 

[F \S = {( 77 , rf) | V(x : A) £ V. („(*), rf(x)) 6 [A]<5} 
Theorem 1. IfA;T h e : A, then for all S £ [A] and ( [r],rf) £ 

[ri4(»,|e]V)eM5. 

Proof. (Sketch) By induction on the derivation of A; T h e : A. 
The most interesting cases are for fix and primRec. In essence, the 
case for fix goes through by induction on the value of the counter 
assigned to the clock variable n in the current clock environment. 
The case for primRec is given by Lemma 1 and Lemma 4. □ 

Corollary 1. If —; — P e : A then for all 77 , [ejrj _L 

By this corollary, the denotation of a closed program is never 
_L, so well-typed programs always yield a proper value. When the 
result type A is the stream type 'in.pX.B x t>X, we can deduce 
that the denotation of e will always be infinite streams of elements 


of B. We further elaborate this point in the next section, showing 
that this type is the carrier of the final (B x —) -coalgebra. 

4. Properties of fixpoint types 

Using the denotational model of the previous section, we are now in 
a position to formally state and sketch the proofs of the properties of 
fixpoint types that we claimed in Section 1.4. Our claimed results 
are statements in category theoretic language about the initiality 
and finality of various (co)algebras. Therefore, we first construct 
suitable categories to work in. 

Definition 1. For each clock variable context A, the category 
ClkPER(A) has as objects semantic types over A. Morphisms 
f : A -4 B are continuous functions f : D —y D such that for 
all 5 6 [A] and (a, o') 6 AS, (fa, fa') £ BS. Two morphisms 
f,f are considered equivalent if for all S £ [A] and (a, a') £ AS, 
(fa, fa') £ BS. 

Each well-typed term A; x : A h e : B defines a morphism 
[e] : [A| -4 [.B] in ClkPER(A). We can define equality between 
terms in our syntactic type system in terms of the equality on mor¬ 
phisms in this definition. Moreover, each well-formed type opera¬ 
tor A;Ih F[X] : type defines a (strong) realisable endofunctor 
on ClkPER(A) that is monotonic on objects, using the semantic 
fmap F defined in Figure 5 to define the action on morphisms. We 
have already checked (Lemma 4) that this is well-defined, and it is 
straightforward to check that the usual functor laws hold. In what 
follows, whenever we refer to an endofunctor on ClkPER(A), we 
mean a realisable functor that is monotonic on objects, and we will 
use fmap F to refer to the action of a functor F on morphisms. 

Initial Algebras Recall that, for any functor F, an F-algebra 
is a pair of an object A and a morphism k : FA —} A. A 
homomorphism h between (A,kA) and (Ft, ks) is a morphism 
h ■. A —>■ B such that ho A; a = kB°fmap F h. An initial F-algebra 
is an F-algebra (A, A;a) such that for any other F-algebra (B, kn), 
there is a unique homomorphism h : (A, kA) —> (B, kB). 

Theorem 2. If F is an endofunctor on ClkPER(A), then pF is 
the carrier of an initial F-algebra. 

Proof. (Sketch) Since pF is a fixpoint of F, the morphism F(pF) -4 
pF is simply realised by the identity map. Given any other F- 
algebra (B, kB), define a morphism pF -4 B using the primrec 
operator from Lemma 1 . Checking that this gives an F-algebra ho¬ 
momorphism is straightforward, proving uniqueness uses induction 
on elements of pF, by the Knaster-Tarski theorem. □ 

Guarded Final Co-Algebras Theorem 2 applies to all functors 
F, and in particular functors of the form F(c?—) on the category 
ClkPER(A, k). As well as p(F( pP—)) being the carrier of an 
initial algebra, it is also the carrier of a final F(c^—)-coalgebra. 

Coalgebras are the formal dual of algebras: for an endofunctor 
F, an F-coalgebra is a pair of an object A and a morphism kA : 

A —> FA. A homomorphism h : (A, kA) —> (B, ks) of coalge¬ 
bras is a morphism h : A —> B such that fmap F h o kA = kB °h. 

A final F-coalgebra is an F-coalgebra (B,ks) such that for any 
other F-coalgebra (A,kA), there is a unique F-coalgebra homo¬ 
morphism unfold kA ■ (A, kA ) —> (B, ks). 

Theorem 3. IfF is an endofunctor on ClkPER(A), then p(F(tfi—)) 
is the carrier of a final F([F‘—)-coalgebra in ClkPER(A, k). 

Proof. (Sketch) As for Theorem 2, since p(F( pP—)) is a fixpoint 
of F(t£-), the morphism p(F( c?-)) F(&(p(F(&-)))) is 
simply realised by the identity map. Given any other F-coalgebra 
(A, kA), define a morphism unfold fc .4 : A p(F( t£—)) as 

fix (A g a. fmap F g (kA a)). It is straightforward to prove that this 




is an F-coalgebra homomorphism. Uniqueness is proved for each 
possible clock environment 6 by induction on S(k). ■•jggf. 

The syntactic counterpart of the construction we used in this 
proof is exactly the term we used in Section 1.4 for the definition 
of unfold. It is also easy to check that the term deCons we defined 
there is semantically equivalent to the identity. Therefore, Theorem 
3 substantiates the claim we made in Section 1.4 that fj,X.F[tP—] is 
the syntactic description of the carrier of a final F[c^—]-coalgebra. 

Final Co-Algebras Theorem 3 gives final coalgebras in the cate¬ 
gories ClkPER(A, k), where we have a spare clock variable. By 
using clock quantification, we can close over this clock variable, 
and get the final F-coalgebra, not just the final F(c?—)■-coalgebra. 
Theorem 4. For an endofunctor F on ClkPER(A), V K ./z(F(C? -)) 
is the carrier of a final F-coalgebra in ClkPER(A). 

Proof. (Sketch) Almost identical to the proof for Theorem 3. O 

This final theorem, along with the examples we presented in 
Section 2.5, substantiates our claim that the combination of clocks 
and guards that we have presented in this paper is a viable and 
comfortable setting in which to productively coprogram. 

5. Conclusions and Further Work 

We have presented a semantics for a small total calculus with 
primitive recursion for inductive data and a compositional treat¬ 
ment of corecursion, ensuring causality via the applicative struc¬ 
ture of a local notion of time. In effect, we use time-based typing 
to grow a given total language, where all computation terminates 
within one ‘day’, into a larger total language, where additional 
recursion is justified clearly by the advancing clock. Functions 
from clocked inputs to clocked outputs enforce precise producer- 
consumer contracts—today’s output must be computed only from 
today’s input—documenting their utility as components of pro¬ 
ductive processes. Quantifying clock variables localises the time 
stream to a particular construction whose clients can then use it ‘in 
the moment’. The method, made local, can be iterated, with inner 
clocks justifying the totality of computations within one ‘day’ of 

At present, however, we have used local time only to justify 
productive corecursion, with only primitive recursion for inductive 
types. It seems pressing to ask whether local time might similarly 
liberalise termination checking, with a local clock measuring time 
into the past and ensuring that recursive calls receive old enough 
inputs that their outputs are ready when we need them. We are 
actively seeking a semantics for such a system, but it currently 
seems more difficult to pin down. 

In due course, we should like to grow this experimental calculus 
to a full blown dependent type theory where (co)recursive construc¬ 
tions are checked to be total within nested local time streams, then 
exported to their clients without clocking. At least we have now es¬ 
tablished what local time streams are and how to extract productive 
processes from them. 
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